Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » U++ TheIDE » U++ TheIDE: Other Features Wishlist and/or Bugs » [PROPOSAL] A couple of changes in "import.ext"
[PROPOSAL] A couple of changes in "import.ext" [message #56920] Fri, 30 April 2021 14:02 Go to next message
mdelfede is currently offline  mdelfede
Messages: 1307
Registered: September 2007
Ultimate Contributor
Importing a large library with "import.ext" I got a couple of probmems:

1) Some files need to be excluded / included depending on platform.
A nice way would be something like
files(PLATFORM_POSIX)
    files.cpp
    dir1/*.cpp
;
exclude(PLATFORM_WIN32)
    an_unix_file.cpp
;


2) A big problem is that object files are put ALL in ONE folder. If the library
has something like this:
    dir1/MyNiceModule.cpp
    dir2/MyNiceModule.cpp

build will fail because second MyNiceModule.o is placed in same output folder and overwrites first one.
The solution could be to put .o files in subfolder or add a prefix like dir1_MyNiceModule.o.

Ciao

Massimo
Re: [PROPOSAL] A couple of changes in "import.ext" [message #56935 is a reply to message #56920] Sat, 01 May 2021 18:19 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
I am all for it (after 2021.1 release).

If you could look into it (ide/Builders/CppBuilder.cpp:262), I will be happy to integrate the patch. If not, I will do it myself, some nice sunny or cloudy day in the future when I have time and mood... Smile

Re: [PROPOSAL] A couple of changes in "import.ext" [message #56943 is a reply to message #56935] Sun, 02 May 2021 18:40 Go to previous messageGo to next message
mdelfede is currently offline  mdelfede
Messages: 1307
Registered: September 2007
Ultimate Contributor
For point 1 I can try it... just a question : the directives in import.ext are processed sequentially ?
I mean :

files somefolder/*.cpp;
exclude somefolder/platforms/*;
files somefolder/platforms/posix/*.cpp;


will pull in all somefolder cpp files, excluding somefolder/plaforms folders but including somefolder/plaforms/posix folders ?

For point 2, I see it more difficult without tampering with all build system.

[Updated on: Sun, 02 May 2021 18:41]

Report message to a moderator

Re: [PROPOSAL] A couple of changes in "import.ext" [message #56946 is a reply to message #56943] Mon, 03 May 2021 08:45 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
mdelfede wrote on Sun, 02 May 2021 18:40
For point 1 I can try it... just a question : the directives in import.ext are processed sequentially ?
I mean :

files somefolder/*.cpp;
exclude somefolder/platforms/*;
files somefolder/platforms/posix/*.cpp;


will pull in all somefolder cpp files, excluding somefolder/plaforms folders but including somefolder/plaforms/posix folders ?


Yes. I gave you a pointer to the code, did not I?

Quote:

For point 2, I see it more difficult without tampering with all build system.


Yes. Which is probably a good thing.

Mirek
Re: [PROPOSAL] A couple of changes in "import.ext" [message #56950 is a reply to message #56946] Mon, 03 May 2021 10:15 Go to previous messageGo to next message
Oblivion is currently offline  Oblivion
Messages: 1091
Registered: August 2007
Senior Contributor
This is a good idea, but for the record, there is already a serious problem with unrecognized keywords/flags/text in ext files, which I had reported here.


Best regards,
Oblivion


Re: [PROPOSAL] A couple of changes in "import.ext" [message #56957 is a reply to message #56946] Tue, 04 May 2021 01:30 Go to previous messageGo to next message
mdelfede is currently offline  mdelfede
Messages: 1307
Registered: September 2007
Ultimate Contributor
mirek wrote on Mon, 03 May 2021 08:45


Yes. I gave you a pointer to the code, did not I?


Yep, and the part 1 is almost done. I just need to know which flags are available at build time and how to read them... if you
can point me in the right direction you'll spare me some time.
By now I added an optional (flags) part, where 'flags' can be any expression, for example:
TRUE
true
1
FALSE
false
0
!flag && (flag1 || flag2)
!flag && flag1 || flag2

with ! (or ~) is the negation, && is AND, || is OR, precedence is UNARY > && > ||.

For example:
files mypath/*.cpp;


Behaves as usual.
files(flagPosix && !flagSomething) mypath/*.cpp;

fetches the files only if flagPosix is true and flagSomething is false.
This applies also to other items (include, exclude, etc).


Just need to evaluate the flag(s) and it's complete.

Ciao

Max

[Updated on: Tue, 04 May 2021 01:31]

Report message to a moderator

Re: [PROPOSAL] A couple of changes in "import.ext" [message #56959 is a reply to message #56957] Tue, 04 May 2021 07:50 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
mdelfede wrote on Tue, 04 May 2021 01:30
mirek wrote on Mon, 03 May 2021 08:45


Yes. I gave you a pointer to the code, did not I?


Yep, and the part 1 is almost done. I just need to know which flags are available at build time and how to read them... if you
can point me in the right direction you'll spare me some time.
By now I added an optional (flags) part, where 'flags' can be any expression, for example:
TRUE
true
1
FALSE
false
0
!flag && (flag1 || flag2)
!flag && flag1 || flag2

with ! (or ~) is the negation, && is AND, || is OR, precedence is UNARY > && > ||.

For example:
files mypath/*.cpp;


Behaves as usual.
files(flagPosix && !flagSomething) mypath/*.cpp;

fetches the files only if flagPosix is true and flagSomething is false.
This applies also to other items (include, exclude, etc).


Just need to evaluate the flag(s) and it's complete.

Ciao

Max


Is it using MatchWhen? It should.

Flags will need to be passed as additional parameter.
Re: [PROPOSAL] A couple of changes in "import.ext" [message #56960 is a reply to message #56959] Tue, 04 May 2021 08:10 Go to previous messageGo to next message
mdelfede is currently offline  mdelfede
Messages: 1307
Registered: September 2007
Ultimate Contributor
mirek wrote on Tue, 04 May 2021 07:50

Is it using MatchWhen? It should.


Nope, I wrote a quick-and-dirty expression evaluator on the fly... had no idea
about MatchWhen... I see that I reinvented the wheel, as usual.
Btw, my flags fetching question is still open... where are available flags ?
Re: [PROPOSAL] A couple of changes in "import.ext" [message #56961 is a reply to message #56960] Tue, 04 May 2021 08:18 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
mdelfede wrote on Tue, 04 May 2021 08:10
mirek wrote on Tue, 04 May 2021 07:50

Is it using MatchWhen? It should.


Nope, I wrote a quick-and-dirty expression evaluator on the fly... had no idea
about MatchWhen... I see that I reinvented the wheel, as usual.
Btw, my flags fetching question is still open... where are available flags ?


Quote:

Flags will need to be passed as additional parameter.


Check ide/Builders/GccBuilder.cpp:88
Re: [PROPOSAL] A couple of changes in "import.ext" [message #56962 is a reply to message #56959] Tue, 04 May 2021 09:44 Go to previous messageGo to next message
mdelfede is currently offline  mdelfede
Messages: 1307
Registered: September 2007
Ultimate Contributor
mirek wrote on Tue, 04 May 2021 07:50

Is it using MatchWhen? It should.


Mhhhh... You mean I shall use ReadWhen to extract the expression in string format and
then use MatchWhen over it ?
My way used the parser directly.
What do you thing about exposing
static bool sMatchOr(CParser& p, const Vector<String>& flag)

As public function, for example overloading MatchWhen:
bool MatchWhen(CParser& p, const Vector<String>& flag)
{
    return sMatchOr(p, flag);
}

So it's possible to do :
bool CheckImportCondition(CParser &p, const Vector<String>& flag)
{
	// no condition == true
	if(!p.Char('('))
		return true;
	bool res = MatchWhen(p, flag);
	p.PassChar(')');
	return res;
}


??
Re: [PROPOSAL] A couple of changes in "import.ext" [message #56972 is a reply to message #56962] Tue, 04 May 2021 23:11 Go to previous messageGo to next message
mdelfede is currently offline  mdelfede
Messages: 1307
Registered: September 2007
Ultimate Contributor
Ok... first mod is done.
With this patch ide accepts optional (flag) inside import.ext file.

I don't remember the way to contribute, so I'm attaching a svn diff here.

Ciao

Max
Re: [PROPOSAL] A couple of changes in "import.ext" [message #56974 is a reply to message #56972] Tue, 04 May 2021 23:21 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
mdelfede wrote on Tue, 04 May 2021 23:11
Ok... first mod is done.
With this patch ide accepts optional (flag) inside import.ext file.

I don't remember the way to contribute, so I'm attaching a svn diff here.

Ciao

Max


It is ok. It just has to wait after 2021.1 is released. Please remind me again by then...

Mirek
Re: [PROPOSAL] A couple of changes in "import.ext" [message #56975 is a reply to message #56974] Tue, 04 May 2021 23:46 Go to previous messageGo to next message
mdelfede is currently offline  mdelfede
Messages: 1307
Registered: September 2007
Ultimate Contributor
mirek wrote on Tue, 04 May 2021 23:21

It is ok. It just has to wait after 2021.1 is released. Please remind me again by then...
Mirek


Ok, thanx!
I hope to have some time for other 2 patches.
Forst onw is to allow duplicate source file names in different folders:
folder1/version.cpp
folder2/version.cpp
folder2/version.c

which could be compiled as
folder1_version.cpp.o
folder2_version.cpp.o
folder2_version.c.o

For example.
The other one is to allow to reference an upper folder (now it doesn't work) :
files ../upperfolder/*.cpp

which is useful to separate a library in many nested packages.
nest
   mypackage
     mylibcode
     mypackage.upp (referencing mylibcode as mylibcode/*.cpp in ext file)
     myplugin
        myplugin.upp (referencing mylibcode as ../mylibcode/*.cpp in ext file)


I guess this could allow import of most libraries.
Re: [PROPOSAL] A couple of changes in "import.ext" [message #56976 is a reply to message #56975] Wed, 05 May 2021 14:25 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
mdelfede wrote on Tue, 04 May 2021 23:46
mirek wrote on Tue, 04 May 2021 23:21

It is ok. It just has to wait after 2021.1 is released. Please remind me again by then...
Mirek


Ok, thanx!
I hope to have some time for other 2 patches.
Forst onw is to allow duplicate source file names in different folders:
folder1/version.cpp
folder2/version.cpp
folder2/version.c

which could be compiled as
folder1_version.cpp.o
folder2_version.cpp.o
folder2_version.c.o

For example.
The other one is to allow to reference an upper folder (now it doesn't work) :
files ../upperfolder/*.cpp

which is useful to separate a library in many nested packages.
nest
   mypackage
     mylibcode
     mypackage.upp (referencing mylibcode as mylibcode/*.cpp in ext file)
     myplugin
        myplugin.upp (referencing mylibcode as ../mylibcode/*.cpp in ext file)


I guess this could allow import of most libraries.


I actually think this problem might be there even without import.ext, so it is definitely worth fixing...
Re: [PROPOSAL] A couple of changes in "import.ext" [message #56978 is a reply to message #56976] Wed, 05 May 2021 17:31 Go to previous messageGo to next message
mdelfede is currently offline  mdelfede
Messages: 1307
Registered: September 2007
Ultimate Contributor
mirek wrote on Wed, 05 May 2021 14:25


I actually think this problem might be there even without import.ext, so it is definitely worth fixing...


Agree... but now there's a problem : how shall we fix it ?

solution 1 :
/home/massimo/sources/OSG/OSG/OpenSceneGraph/src/osgWidget/Util.cpp
-->
outputdir/_home_massimo_sources_OSG_OSG_OpenSceneGraph_src_osgWidget_Util.cpp.o

which I'm afraid will make windows command line limitations quite unhappy when linking the whole stuff.

solution 2 :
/home/massimo/sources/OSG/OSG/OpenSceneGraph/src/osgWidget/Util.cpp
-->
outputdir/home/massimo/sources/OSG/OSG/OpenSceneGraph/src/osgWidget/Util.cpp.o

probably same problem as point 1 on windows, with directory tree management plus

solution 3 :
strip all "common" path part from sources and use just the remaining as solution 1
/home/massimo/sources/OSG/OSG/OpenSceneGraph/src/osgWidget/Version.cpp
/home/massimo/sources/OSG/OSG/OpenSceneGraph/src/osgUtil/Version.cpp
-->
outputdir/osgWidget_Version.cpp.o
outputdir/osgUtil_Version.cpp.o

this should make windows linker happy, but it will cause complete rebuild if we add some new source file
having a different path and needs a source files preventive scan to get the common path part.

solution 4 :
some sort of file mapping
/home/massimo/sources/OSG/OSG/OpenSceneGraph/src/osgWidget/Version.cpp
/home/massimo/sources/OSG/OSG/OpenSceneGraph/src/osgUtil/Version.cpp
-->
outputdir/1.o
outputdir/2.o

The map could be stored in output folder along with object files, and updated on demand.
IMHO that one would be the better solution...

what do you think about ?
Re: [PROPOSAL] A couple of changes in "import.ext" [message #56979 is a reply to message #56978] Wed, 05 May 2021 19:18 Go to previous messageGo to next message
mdelfede is currently offline  mdelfede
Messages: 1307
Registered: September 2007
Ultimate Contributor
Attached file implements solution 4 for GCCBuilder... it seems to work.
It create obj files in form of 00000000.o ... 99999999.o and stores in a map the relationship between
source file and obj file, which is recorded as OBJFILES.MAP in output folder.

If you agree with this method, I can do it also for MSC builder.

Ciao

Max
Re: [PROPOSAL] A couple of changes in "import.ext" [message #56980 is a reply to message #56978] Thu, 06 May 2021 08:09 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
mdelfede wrote on Wed, 05 May 2021 17:31

which I'm afraid will make windows command line limitations quite unhappy when linking the whole stuff.


You do not have to worry about that, we are using response files (that is basically commandline in a file) when commandline is too long. Hit that limit even as things are now.

I think that somethine like (1) is probably the best.

Mirek

Re: [PROPOSAL] A couple of changes in "import.ext" [message #56982 is a reply to message #56980] Thu, 06 May 2021 16:02 Go to previous messageGo to next message
mdelfede is currently offline  mdelfede
Messages: 1307
Registered: September 2007
Ultimate Contributor
Hi,

here the complete patch.
Tested (quickly) on Linux, so no MSC builder, I'll do it if it's all ok.

'import.ext' now accepts flags:
files(POSIX & !SOMETHING) some/path/*.cpp


allows relative paths (from current package) and absolute paths (useless, but anyways):
files(POSIX & !SOMETHING) ../myoriginallib/some/path/*.cpp
files /home/massimo/some/path/*.c


and finally allows duplicate file names in different paths and in c/c++/cxx files:
files some/path/version.cpp
files another/path/version.cpp
files another/path/version.c


object files are put in output directory with names prepended with original paths and with source extension before .o :
some/path/test.cpp --> outdir/package_full_path_some_path_test.cpp.o


Patch is attached. Please tell if it's ok and if I shall do the same for MSC too.


  • Attachment: ide.patch
    (Size: 7.33KB, Downloaded 93 times)

[Updated on: Thu, 06 May 2021 16:04]

Report message to a moderator

Re: [PROPOSAL] A couple of changes in "import.ext" [message #57020 is a reply to message #56982] Sat, 15 May 2021 10:35 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Unfortunately, patch is against outdated CppBuilder.cpp (bug reported by Oblivion was fixed meanwhile), so it cannot be applied (I have actually spent some time trying to figure out whether this is not a bug in TheIDEs "Apply patch" function, but it really is not).

Before I start fixing the patch, maybe you could send me the plain CppBuilder.cpp?

Re: [PROPOSAL] A couple of changes in "import.ext" [message #57023 is a reply to message #57020] Sat, 15 May 2021 14:26 Go to previous messageGo to previous message
mdelfede is currently offline  mdelfede
Messages: 1307
Registered: September 2007
Ultimate Contributor
I can try to re-fetch the three and apply my patch on updated code... just wait a little.
I changed both cppbuilder and gccbuilder (latter, iirc, for adding path to output file names).
Previous Topic: Import external library - Include files depending on OS
Next Topic: [BUG] Preprocess + pkg-config
Goto Forum:
  


Current Time: Thu Mar 28 10:07:50 CET 2024

Total time taken to generate the page: 0.01268 seconds