I find it rather unfortunate that given that Fortran 90 has been around since the 90's, it seems makepp cannot yet handle it. Does anybody have a scanner for Fortran 90 and a way to figure out dependencies not based on "include", but on use <module-name> ? Any other hints appreciated.
Duplicate requires in META.yml
Hello, after a long time I have to implement new rules in our Makeppfile where I would have to use $(changed_inputs). But it is daunting me that either the description of $(changed_inputs) is incomplete or my understanding is totally flawed. Please have a look to this Makeppfile: SOURCES += a.t b.t c.t $(foreach).dep : $(foreach) : foreach $(SOURCES) : signature md5 md5sum $(input) > $(output) summary.dep : $(SOURCES).dep : signature md5 : build_check ignore_action md5sum $(changed_inputs) > $(output)...
I'm trying to use an existing GNU Makefile with makepp, and hit an issue which I fully explain in this git repo: https://github.com/scottj97/makepp-wildcard-issue Briefly, include $(wildcard ...) tries to include nonexistent files which makepp doesn't know how to build, which is contrary to the way $(wildcard) is documented to work in makepp.
We've got a code base that's been using makepp for a while across several different LInux distros (Redhat, and various version of Ubuntu); everything needed to build this codebase is in an svn repo, and you generally just checkout the repo, install makepp on whatever machine you’re on, and the build just works. However, I recently created a new VM running Ubuntu 18 LTS, checked out the repo, installed makepp, and found that I could not build. I tracked the problem down to infer_objects failing. After...
Never mind. I can do this with scanner. I register scanner for this command, and thus it knows the implicit .o dependencies from command line. In the command, I will link $^ if $^ is non-empty, otherwise I will link all .o.
Hi, I'd like to write a makepp rule which links .o files into .a file. If user specifies the dependencies of .a like this: libx.a: a.o b.o c.o libx.a: d.o then we will link a/b/c/d.o into libx.a. If user does not specify dependencies of libx.a, then I'd like to link all .o files that can be built into libx.a. Can anyone help this? Thanks, Justin
Hey Daniel, thank you for your comment. At least partially I have found a solution, let me explain. I am doing no magic with RootMakeppfile or --dont-build at directory trees. A script is creating a temporary run directory, doing cd to it and running there 'mpp -f /<script_path>/Makefile'. This way all input and output files to the make process are outside of the current directory. The metadata beside input files can be omitted by using mpp with '--virtual-sandbox'. But, in directory of output file...
Moin Mirko, if you have a RootMakeppfile or equivalently mark everything outside of your tree as --dont-build, it might be considered a bug that makepp still creates files there. However fixing it would involve quite a few changes, as it is an assumption in various places, that metadata resides just beside the file. :-( One easy way to work around this would be to have everything outside belong to a different user or be in read-only directories. liebe Grüße – Daniel
Hi, I am using makepp inside a utility which takes input files from various directories in the filesystem. For several reasons I choosed to employ MD5 signatures (first line in Makefile is "signature md5"). After a successfull run, mpp leaves an .makepp directory beside every input file in the filesystem (holding the md5 sums for the used files). These residual subdirs are scattered all over the filesystem, wherever mpp looked at a file and the user had write access - this is inconvenient. I am not...
You're thinking in terms of unreliable makes. Of course you have a dependency! There might be a rule to make that include file, so a reliable build tool has to load the makefile to check. If you want to partition into build and read-only parts, you can rename your main makefile to RootMakeppfile. Or if you want to remember to use options: --dont-build=/opensource or --do-build=/development As for the bozo comment, that would seem to be a GNU extension, which 15 and more years agom the makepp author...
You're thinking in terms of unreliable makes. Of course you have a dependency! There might be a rule to make that include file, so a reliable build tool has to load the makefile to check. As for the bozo comment, that would seem to be a GNU extension, which 15 and more years agom the makepp author was alas not aware of. Solaris is documented to do it just like the Shell: http://docs.oracle.com/cd/E19253-01/816-5165/6mbb0m9l0/index.html#Usage further down at Globals. So either way, makepp would have...
There was no dependancy, i thought imade that clear. It loaded a makefile that wasn't included. Ignoring 'bozo' syntax seems like an odd choice. You're reading a makefile, and that's part of makefiles syntax. You could read preprocessed output if you prefer by reading the output of make -np
Minor incompatibility between gmake and makepp wrt parsing of # comment and $(info)
warning: Use of uninitialized value in concatenation (.) or string at /usr/local/share/makepp/Mpp/File.pm line 1189.
$(eval) does not redefine variables (GNU make incompatibil)
makepp includes wrong file, then can't handle multi line comment
Makepp has to load a Makefile whereever it finds a needed dependency – else it can't guarentee correct builds. That bozo comment syntax differing from Shell and other #-comment languages, seems a little known edge case. Fixing it might break Makeppfiles.
Sorry, that got mangled, let me try again: root:~# makepp makepp: Loading makefile `/development/Makefile' makepp: Loading makefile `/opensource/Makefile' /development/Makefile:359: error handling Mpp::makefile_0::s_include statement /development/Makefile_rules.mk:72: error handling Mpp::makefile_0::s_include statement /opensource/Makefile:186: syntax error in line ' pygtk-2.12.1 gtk+-2.13.5 fontconfig-2.6.0 DirectFB-1.2.0 atk-1.23.5 cairo-1.6.4 pango-1.21.3 libxml2-2.9.3 libglade-2.6.2 pygobject-2.15.2...
makepp includes wrong file, then can't handle multi line comment
That is alas currently not possible, because SHELL is the executable, not being split...
I wan't to set shell option pipefail. In GNU Make I would just add: SHELL = /bin/bash...
Found the answer, Looks like it has to do with the signature.
I just recently switched to makepp from years of using GNU make, so my apologies...
I'm wondering instead if switching the scanner to a simple Promise API wouldn't be...
Hi Daniel, Thanks again. Yes, it appears that nowarn is not suppressing stale file...
Hi Arul, no, you looked well! The subdir name is stored in $Mpp::File::build_info_subdir,...
Hi Jeffrey, you can use "var ;= value" to get at most a single expansion at the time...
Thanks for the response, Daniel. I can easily get rid of the top-level calls to infer_objects...
Hi, Does makepp support storing build info files in a specified directory instead...
Hi Peter, I finally found time to port your patch to the latest version from CVS....
Hi, option dashes are optional so --no-warn and --nowarn are identical. This was...
After reading some of the other topics on this forum, I thought I'd expand on my...
After reading some of the other topics on this forum, I thought I'd expand on my...
Hi I'm having the same issue as the OP: I'm giving "--no-warn" to makepp, but still...
Also your suggestion of a.c explicitly depend on slowtobuild.h doesn't end up helping....
Thanks :) Sorry for the broken diff, new one attached should work. From poking at...
Hi Peter! So sorry for your effort in vain! It just happened to me too, because I...
My local hack of adding a :pre_depend option was easier than I expected. It's working...
Man SF.net really dislikes me. I just typed out this whole response and it disappeared...
Hi Peter, you are alas right, it requires a major redesign. The idea was already...
Sorry for the broken fromatting, sf.net is weird. Maybe this will work? SLEEPERS...
Scanner causes build serialization
I would consider a bogus uid a pretty buggy setup, though I don't know if docker...
I would consider a bogus uid a pretty buggy setup, though I don't know if docker...
warning: Use of uninitialized value in concatenation (.) or string at /usr/local/share/makepp/Mpp/File.pm line 1189.
Well, for one thing it actuallly is a pattern rule, or rather what makepp makes out...
Hello, I have following rule in my Makeppfile: $(patsubst %.lua, %.luo, $(foreach))...
Dear Group, I have used Make++ for a lot of years already. I have also built a complete...
I faced something what looks like a weird parsing bug in 2.0 line. Details posted...
Hi Andy, I will never be astounded enough by the quirks gmake will come up with....
Hi Andy, I will never be astounded enough by the quirks gmake will come up with....
Minor incompatibility between gmake and makepp wrt parsing of # comment and $(info)
Hi Lezz, No it says: "If it doesn't [look like C or C++ source code], it falls back...
"signature md5" says that it uses an md5 checksum for all dependencies for a build,...
Syntax error with $(MAKE) ... <variable>=<override> ...
shell variable assignments generate invalid deps
shell variable assignments generate invalid deps
Version 2.0 handles this fine.